FeDCOR: An Institutional CORDRA Registry

FeDCOR (Federation of DSpace using CORDRA) is a registry-based federation system for DSpace instances. It is based on the CORDRA model. The first article in this issue of D-Lib Magazine describes the Advanced Distributed Learning-Registry (ADL-R) [1], which is the first operational CORDRA registry, and also includes an introduction to CORDRA. That introduction, or other prior knowledge of the CORDRA effort, is recommended for the best understanding of this article, which builds on that base to describe in detail the FeDCOR approach. Introduction The first instance of a CORDRA registry has been built by CNRI for the ADL-R project. ADL-R is designed to serve the U.S. DoD e-learning community and will be hosted and maintained by the Defense Technical Information Center (DTIC) [2]. Any single CORDRA registry, including ADL-R, provides various value added services, the primary service being the federation of a collection of repositories, but the higher level functionality of CORDRA only comes into play when there are multiple federations, which can themselves be federated. Among the motivations for creating FeDCOR was to begin testing the use of CORDRA to federate heterogeneous communities in a single architecture [3]. DSpace [4] was selected as the institutional repository base to use in the development of a CORDRA registry for the institutional repository community, hence the name FeDCOR (Federation of DSpace using CORDRA). DSpace is a repository system designed to capture, store, index, preserve and redistribute content in various digital formats. Many research institutions and other organizations fitting the library model have found DSpace useful for meeting a variety of digital archiving needs. Although DSpace has succeeded in meeting most of the needs of these organizations, the interoperability of different services across DSpace repositories is a missing feature. The effective federation of DSpace repositories remains a challenge in the digital library community. FeDCOR: An Institutional CORDRA Registry http://www.dlib.org/dlib/february06/manepalli/02manepalli.html[5/10/2016 2:47:52 PM] Building a federation of DSpace repositories using a CORDRA compliant registry would serve two purposes: 1. A federation for DSpace repositories. 2. A CORDRA registry from the library community. The design and implementation of such a registry should be useful both for the DSpace community and the evolving CORDRA community. FeDCOR The logical view of FeDCOR is depicted in Figure 1 below. Figure 1: Logical View of FeDCOR DSpace repositories act as content repositories within FeDCOR. The metadata provided by DSpace for each content object is treated as the metadata instance for that object. DSpace associates handles [5] with the complex object abstraction that incorporates metadata instances and byte streams. At the time of publication of this article, the official distribution of DSpace keeps a handle server per DSpace instance, but work is underway to allow DSpace instances to store and manage their handles through a conventional external handle server [Note 1]. Therefore, FeDCOR assumes the announced future functionality, and assumes each handle for a particular object introduced into a particular DSpace repository to be consistent, even across multiple DSpace implementations. The design of FeDCOR requires assimilating the data access mechanisms of DSpace and thoroughly defining the CORDRA conformant data structures, business rules and taxonomies. The following sections address the process of design, implementation and development of FeDCOR, and provide insight into the process of adapting and deploying a CORDRA Registry for a new community. (1) Design of FeDCOR A registry contains, by reference, the registered content objects and also holds the metadata instances pertaining to these registered content objects. The community Registry should therefore reflect the community's agreed upon metadata instance format. At the same time, the registry should be able to accommodate an upper layer of metadata in order to integrate it with other registries in a registry of registries federation. Fortunately the original CORDRA registry design provides metadata independence at multiple layers/levels. The three possible levels are (as shown in Figure 2): FeDCOR: An Institutional CORDRA Registry http://www.dlib.org/dlib/february06/manepalli/02manepalli.html[5/10/2016 2:47:52 PM] 1. Content Object specific metadata, also known as Community Level Metadata 2. Registry specific metadata 3. CORDRA specific metadata In FeDCOR the three different levels must be strictly defined. Leveraging our experience in the development of ADL-R, it is assumed that CORDRA specific metadata is a subset of the union of metadata from the Registry level and the Content Object level. Figure 2: Metadata Instance Layers Also, CORDRA specific metadata will evolve over a period of time depending on its usage, and the exact usage is unpredictable at this stage. For those reasons, metadata design is derived from registry and content object metadata. Content Object Metadata Instance Definition Content Object Metadata Instance (COMI) is the metadata related to each content object retrieved from DSpace. DSpace implements an extended Dublin Core metadata set and most deployments are compliant OAI-PMH [6] data providers. Since OAI-PMH is a standard protocol used in the digital library community, FeDCOR adopted it as a de-facto data access method for DSpace. The Dublin Core metadata format [7] used by the traditional DSpace communities is compatible to both DSpace and OAI-PMH. Hence the content object metadata is conformant with the oai_dc schema of the OAI-PMH metadata record in Dublin Core. The different elements in the metadata include title, identifier, keywords, timestamp, etc. The metadata records are related to the content object handle associated with both the metadata and the byte streams (the complex object mentioned previously). Since we consider the more general case in which DSpace entities are implementing the DSpace remote handle patch, it is feasible to import the same handle into multiple DSpace repositories. Thereby, the persistence of this handle, and its relationship with the Content Object Representation Entity (CORE) [1] identifier of any particular CORDRA repository, is achieved. In addition to having a unique identifier for the content, CORDRA requires a unique metadata instance identifier associated with content object metadata. FeDCOR follows the same approach as ADL-R, wherein the registry generates and manages the metadata instance handle for each particular metadata instance found inside a particular DSpace repository. The DSpace handle is used as the content object handle. Registry Level Metadata Registry Level Metadata reflects the signature of each registry entry at the level of community specific registry. This signature is important in the realization of CORDRA as a platform for FeDCOR: An Institutional CORDRA Registry http://www.dlib.org/dlib/february06/manepalli/02manepalli.html[5/10/2016 2:47:52 PM] heterogeneous content. It helps to identify the particular registry to which the given entry belongs. Each content object handle, and its metadata instance handle related to its occurrence in a particular DSpace repository, are stored at this level. We also keep track of their update time, so we include the last updated timestamp as part of the registry level metadata. CORDRA Specific Metadata As mentioned above, CORDRA specific metadata is the subset of the union of content object metadata and registry specific metadata. As described in the ADL-R article in this issue of D-Lib Magazine [1], the CORDRA level metadata and procedures are still in testing and development. Fortunately, most of this metadata will be produced by seamless additions or agents to the preexisting CORDRA communities.